1. Field of the Invention
The present invention relates generally to a Broadband Wireless Access (BWA) mobile communication system, and in particular, to a handover system and method for minimizing a service delay due to a pingpong effect.
2. Description of the Related Art
Research into a 4th generation (4G) communication system, which is the next generation communication system, is being conducted to provide users with high-speed services having various Qualities-of-Service (QoSs). More particularly, in the current 4G communication system, active research is being performed on technology supporting high-speed services for guaranteeing mobility and QoS in a BWA communication system such as a wireless Local Area Network (LAN) system and a wireless Metropolitan Area Network (MAN) system, and the conventional communication systems include an Institute of Electrical and Electronics Engineers (IEEE) 802.16a communication system and an IEEE 802.16e communication system.
The IEEE 802.16a and IEEE 802.16e communication systems are communication systems using an Orthogonal Frequency Division Multiplexing (OFDM) scheme and/or an Orthogonal Frequency Division Multiple Access (OFDMA) scheme in order to support a broadband transmission network to a physical channel of the wireless MAN system. The IEEE 802.16a communication system is a system that considers only a state in which a subscriber station (SS) is located in a fixed position, i.e., mobility of an SS is never taken into consideration, and a unicell structure. However, the IEEE 802.16e communication system is a system that considers mobility of an SS in the IEEE 802.16a communication system, and in the IEEE 802.16e communication system, the SS is called a “mobile subscriber station (MSS).”
FIG. 1 is a diagram schematically illustrating a conventional IEEE 802.16e communication system. Referring to FIG. 1, the IEEE 802.16e communication system has a multicell structure, i.e., has a cell 100 and a cell 150, and includes a base station (BS) 110 for managing the cell 100, a BS 140 for managing the cell 150, and a plurality of MSSs 111, 113, 130, 151, and 153. Signal exchange between the BSs 110 and 140 and the MSSs 111, 113, 130, 151, and 153 is achieved using the OFDM/OFDMA scheme. However, among the MSSs 111, 113, 130, 151, and 153, the MSS 130 is located in a boundary region of the cell 150, i.e., a handover region. If the MSS 130 moves in the direction of the cell 150 managed by the BS 140 while exchanging signals with the BS 110, its serving BS is changed from the BS 110 to the BS 140.
FIG. 2 is a signaling diagram illustrating a handover process initiated by an MSS in a conventional IEEE 802.16e communication system. Referring to FIG. 2, a serving BS 210 transmits a Mobile Neighbor Advertisement (MOB_NBR_ADV) message to an MSS 200 in Step 211. A format of the MOB_NBR_ADV message is illustrated in Table 1.
TABLE 1SyntaxSizeNotesMOB_NBR_ADV_Message_Format( ) { Management Message Type = 48 8 bits Operator ID24 bitsUnique IDassigned tothe operator Configuration Change Count 8 bits N_NEIGHBORS 8 bits For (j=0; j<N_NEIGHBORS; j++) {  Neighbor BS-ID48 bits  Physical Frequency32 bits  RLV Encoded Neighbor informationVariableTLV specific }}
As illustrated in Table 1, the MOB_NBR_ADV message includes a plurality of information elements (IEs), i.e., a Management Message Type IE indicating a type of a transmission message, an Operator ID IE indicating a network identifier (ID), a Configuration Change Count IE indicating the number of changes in configuration, an N_NEIGHBORS IE indicating the number of neighbor BSs, a Neighbor BS-ID IE indicating IDs of the neighbor BSs, a Physical Frequency IE indicating a frequency of a physical channel for the neighbor BS, and a TLV (Type, Length, Value) Encoded Neighbor Information IE indicating other information related to the neighbor BS.
The MSS 200 can acquire information on neighbor BSs by receiving the MOB_NBR_ADV message. If the MSS 200 desires to scan carrier-to-interference and noise ratios (CINRs) of pilot signals transmitted from neighbor BSs and the serving BS 210, it transmits a Mobile Scanning Interval Allocation Request (MOB_SCN_REQ) message to the serving BS 210 in Step 213. A format of the MOB_SCN_REQ message is illustrated in Table 2.
TABLE 2SyntaxSizeNotesMOB_SCN_REQ_Message_Format( ) { Management Message Type = ? 8 bits Scan Duration12 bitsUnits are frames Start Frame 4 bits}
As illustrated in Table 2, the MOB_SCN_REQ message includes a plurality of IEs, i.e., a Management Message Type IE indicating a type of a transmission message, a Scan Duration IE indicating a scanning duration for which the MSS 200 desires to scan CINRs of pilot signals received from the neighbor BSs, and a Start Frame IE indicating a frame at which the MSS 200 will start a scanning operation. The Scan Duration is created on a per-frame basis. In Table 2, the Management Message Type indicating a type of a channel over which the MOB_SCN_REQ message will be transmitted has not been defined yet (Management Message Type=Undefined). Because a time at which the MSS 200 makes a scan request is not directly related to a CINR scanning operation for the pilot signals, a detailed description thereof will not be given herein.
Upon receiving the MOB_SCN_REQ message, the serving BS 210 includes information based on which the MSS 200 will perform scanning in a Mobile Scanning Interval Allocation Response (MOB_SCN_RSP) message with Scan Duration≠0, and transmits the MOB_SCN_RSP message to the MSS 200 in Step 215. A format of the MOB_SCN_RSP message is illustrated in Table 3.
TABLE 3SyntaxSizeNotesMOB_SCN_RSP_Message_Format( ) { Management Message Type = ? 8 bits For (i=0; i<num_CIDs; i++) {num_CIDs can bedetermined fromthe length of themessage (foundin the genericMAC header)  CID16 bitsbasic CID of theMSS  Duration12 bitsin frames  Estimated time for handover 8 bits  Start Frame 4 bits }}
As illustrated in Table 3, the MOB_SCN_RSP message includes a plurality of IEs, i.e., a Management Message Type IE indicating a type of a transmission message, a Connection ID (CID) IE indicating a CID of the MSS 200 that transmitted the MOB_SCN_REQ message, a Scan Duration IE, and a Start Frame IE indicating a time at which a scanning operation will starts. In Table 3, the Management Message Type indicating a type of a channel over which the MOB_SCN_RSP message will be transmitted has not been defined yet (Management Message Type=Undefined). The Scan Duration indicates a scanning duration for which the MSS 200 performs the pilot CINR scanning, and if the Scan Duration is set to ‘0’ (Scan Duration=0), it indicates that the scan request of the MSS 200 is rejected.
Upon receiving the MOB_SCN_RSP message including the scanning information, the MSS 200 performs CINR scanning on the pilot signals received from the serving BS 210 and neighbor BSs acquired through reception of the MOB_NBR_ADV message according to parameters, i.e., Scan Duration, included in the MOB_SCN_RSP message in Step 217.
After completing CINR scanning on the pilot signals received from the neighbor BSs and the serving BS 210, the MSS 200 determines if it should change its current serving BS to a new serving BS being different from the serving BS 210 in Step 219. When the MSS 200 determines to changes its current BS, the MSS 200 transmits a Mobile Subscriber Station Handover Request (MOB_MSSHO_REQ) message to the serving BS 210 in Step 221. Herein, a new BS other than the serving BS to which the MSS 200 currently belongs, i.e., a possible new serving BS to which the MSS 200 will be handed over, will be referred to as a “target BS.” A format of the MOB_MSSHO_REQ message is illustrated in Table 4.
TABLE 4SyntaxSizeNotesMOB_MSSHO_REQ_Message_Format( ) { Management Message Type = 52 8 bits For (j=0; j<N_Recommended; j++) {)N_Recommended can be derivedfrom the known length of themessage  Neighbor BS-ID48 bits  BS S/(N+I) 8 bits  Service level prediction 8 bits  Estimated HO Time 8 bits }}
As illustrated in Table 4, the MOB_MSSHO_REQ message includes a plurality of IEs, i.e., a Management Message Type IE indicating a type of a transmission message and the scanning results acquired by the MSS 200. In Table 4, N_Recommended indicates the number of neighbor BSs that transmitted pilot signals of which CINRs are higher than or equal to a predetermined CINR, as a result of CINR scanning on the pilot signals from the neighbor BSs by the MSS 200. That is, the N_Recommended indicates the number of neighbor BSs handover-recommended by the MSS 200. The MOB_MSSHO_REQ message includes IDs of neighbor BSs indicated by the N_Recommended, CINRs of pilot signals from the neighbor BSs, a service level predicted to be provided to the MSS 200 by the neighbor BSs, and an estimated handover time (Estimated HO Time) at which the MSS 200 will select one of the neighbor BSs as a target BS and start handover to the target BS.
Upon receiving the MOB_MSSHO_REQ message transmitted by the MSS 200, the serving BS 210 detects a list of candidate target BSs to which the MSS 200 can be handed over, from N_Recommended information in the received MOB_MSSHO_REQ message in Step 223. Herein, the list of candidate target BSs to which the MSS 200 can be handed over will be referred to as a “candidate target BS list,” and it will be assumed in FIG. 2 that the candidate target BS list has a first target BS 220 and a second target BS 230. The candidate target BS list can also include a plurality of target BSs in addition to the two target BSs.
The serving BS 210 transmits HO_PRE_NOTIFICATION messages to the target BSs included in the candidate target BS list, i.e., the first target BS 220 and the second target BS 230 in Steps 225 and 227. A format of the HO_PRE_NOTIFICATION message is illustrated in Table 5.
TABLE 5FieldSizeNotesGlobal Header152-bitFor (j=0; j<Num Records; j++) { MSS unique identifier 48-bit48-bit unique identifier usedby MSS (as provided bythe MSS or by the I-am-host-of message) Estimated Time to HO 16-bitIn milliseconds, relative to thetime stamp, value 0 of thisparameter indicates that noactual HO is pending Required BW 8-bitBandwidth which is requiredby MSS (to guaranteeminimum packet datatransmission) Required QoS 8-bitName of Service ClassrepresentingAuthorizedQoSParam-Set}Security fieldTBDA means to authenticate thismessageCRC field 32-bitIEEE CRC-32
As illustrated in Table 5, the HO_PRE_NOTIFICATION message includes a plurality of IEs, i.e., Global Header which is commonly included in messages exchanged between BSs in a backbone network, MSS ID of the MSS 200 that desires to be handed over to the first target BS 220 or the second target BS 230, estimated handover time (Estimated Time to HO) indicating an estimated time at the MSS 200 will start handover, Required BW indicating information on a bandwidth for which the MSS 200 requests a target BS which will become a new serving BS, and Required QoS indicating information on a service level desired by the MSS 200. The bandwidth (BW) and the service level (QoS) requested by the MSS 200 are equal to the predicted service level information written in the MOB_MSSHO_REQ message described with reference to Table 4.
A format of the general Global Header commonly included in messages exchanged between BSs in a backbone network, like the HO_PRE_NOTIFICATION message, is illustrated in Table 6.
TABLE 6FieldSizeNotesMessage Type = ? 8-bitSender BS-ID48-bitBase station unique identifier (Same numberas that broadcasted on the DL-MAPmessage)Target BS-ID48-bitBase station unique identifier (Same numberas that broadcasted on the DL-MAPmessage)Time Stamp32-bitNumber of milliseconds since midnightGMT (set to 0xffffffff to ignore)Num Records16-bitNumber of MSS identity records
As illustrated in Table 6, the Global Header includes a plurality of IEs, i.e., Message Type indicating a type of a transmission message, Sender BS-ID indicating a transmission BS that transmits the transmission message, Target BS-ID indicating a reception BS that receives the transmission message, and Num Records indicating the number of MSSs corresponding to records included in the transmission message.
Upon receiving the HO_PRE_NOTIFICATION messages from the serving BS 210, the first target BS 220 and the second target BS 230 transmit HO_PRE_NOTIFICATION_RESPONSE messages to the serving BS 210 in response to the HO_PRE_NOTIFICATION messages in Steps 229 and 231. A format of the HO_PRE_NOTIFICATION_RESPONSE message is illustrated in Table 7.
TABLE 7FieldSizeNotesGlobal Header152-bitFor (j=0; j<Num Records; j++) { MSS unique identifier 48-bit48-bit unique identifierused by MSS (as providedby the MSS or by the I-am-host-of message) BW Estimated 8-bitBandwidth which is providedby BS (to guaranteeminimum packet datatransmission) TBD howto set this field QoS Estimated 8-bitQuality of Service levelUnsolicited Grant Service(UGS)Real-time Polling Service(rtPS)Non-real-time Polling Service(nrtPS)Best Effort ACK/NACK 8-bitAcknowledgement orNegative Acknowledgement1 is Acknowledgment whichmeans that the neighbor BSaccepts the HO-pre-notification messagefrom the Serving BS0 is NegativeAcknowledgement whichmeans that the neighborBS may not accept theHO-pre-notificationmessage from the ServingBS}Security FieldTBDA means to authenticatethis messageCRC field 32-bitIEEE CRC-32
As illustrated in Table 7, the HO_PRE_NOTIFICATION_RESPONSE message includes a plurality of IEs, i.e., a Global Header which is commonly included in messages exchanged between BSs in a backbone network as described with reference to Table 6, an MSS ID of the MSS 200 that desires to be handed over to the target BSs, an ACK/NACK indicating whether the target BSs can perform handover in response to an handover request from the MSS 200, and bandwidth and service level information for indicating a bandwidth and a service level supportable by the target BSs to which the MSS 200 is handed over.
Upon receiving the HO_PRE_NOTIFICATION_RESPONSE messages from the first target BS 220 and the second target BS 230, the serving BS 210 analyzes the HO_PRE_NOTIFICATION_RESPONSE messages received from the first target BS 220 and the second target BS 230, and selects a target BS that can optimally support the bandwidth and service level requested by the MSS 200 after handover, as a final target BS to which the MSS 200 will be handed over. For example, if it is assumed that a service level supportable by the first target BS 220 is lower than the service level requested by the MSS 200 and a service level supportable by the second target BS 230 is equal to the service level requested by the MSS 200, the serving BS 210 selects the second target BS 230 as a final target BS to which the MSS 200 will be handed over. Therefore, the serving BS 210 transmits a HO_CONFIRM message to the second target BS 230 in response to the HO_PRE_NOTIFICATION_RESPONSE message in Step 233. A format of the HO_CONFIRM message is illustrated in Table 8.
TABLE 8FieldSizeNotesGlobal Header152-bitFor (j=0; j<Num Records; j++) { MSS unique identifier 48-bit48-bit universal MACaddress of the MSS (asprovided to the BS onthe RNG-REQ message) BW Estimated 8-bitBandwidth which isprovided by BS (toguarantee minimum packetdata transmission) TBDhow to set this field QoS Estimated 8-bitQuality of Service LevelUnsolicited Grant Service(UGS)Real-time Polling Service(rtPS)Non-real-time Polling Service(nrtPS)Best Effort Service (BE)}Security fieldTBDA means to authenticatethis messageCRC field 32-bitIEEE CRC-32
As illustrated in Table 8, the HO_CONFIRM message includes a plurality of IEs, i.e., a Global Header which is commonly included in messages exchanged between BSs in a backbone network as described with reference to Table 6, an MSS ID of the MSS 200 that desires to be handed over to the selected target BS, and bandwidth and service level information for indicating a bandwidth and a service level supportable by the selected target BS to which the MSS 200 is handed over.
In addition, the serving BS 210 transmits a Mobile BS Handover Response (MOB_BSHO_RSP) message to the MSS 200 in response to the MOB_MSSHO_REQ message in Step 235. Herein, the MOB_BSHO_RSP message includes information on a target BS to which the MSS 200 will be handed over. A format of the MOB_BSHO_RSP message is illustrated in Table 9.
TABLE 9SyntaxSizeNotesMOB_BSHO_RSP_Message_format( ) { Management Message Type = 53 8 bits Estimated HO time 8 bits For (j=0; j<N_Recommended; j++) {Neighbor base stations shall be presented in anorder such that the first presented is the one mostrecommended and the last presented is the leastrecommended. N_Recommended can be derivedfrom the known length of the message.  Neighbor BS-ID48 bits service level prediction 8 bits }}
As illustrated in Table 9, the MOB_BSHO_RSP message includes a plurality of IEs, i.e., a Management Message Type indicating a type of a transmission message, an Estimated HO time indicating an estimated time at which a handover procedure will start, and information on target BSs selected by the serving BS. In addition, N_Recommended in the MOB_BSHO_RSP message indicates the number of target BSs satisfying the bandwidth and service level requested by the MSS 200, among the target BSs in the candidate target BS list. The MOB_BSHO_RSP message includes IDs for target BSs indicated by the N_Recommended, and a predicted service level supportable to the MSS 200 by the target BSs. Although only the information on one target BS of the second target BS 230 among the target BSs existing in the candidate target BS list is finally included in the MOB_BSHO_RSP message in FIG. 2, if there are several target BSs satisfying the bandwidth and service level requested by the MSS 200 among the target BSs existing in the candidate target BS list, information on the several target BSs is included in the MOB_BSHO_RSP message.
Upon receiving the MOB_BSHO_RSP message, the MSS 200 analyzes N_Recommended information included in the received MOB_BSHO_RSP message, and selects a target BS to which it will be handed over based on the analysis result.
After selecting the target BS, the MSS 200 transmits a Mobile Handover Indication (MOB_HO_IND) message to the serving BS 210 in response to the MOB_BSHO_RSP message in Step 237. A format of the MOB_HO_IND message is illustrated in Table 10.
TABLE 10SyntaxSizeNotesMOB HO IND Message Format( ) { Management Message Type = 54 8 bits reserved 6 bitsReserved; shall be setto zero HO_IND_type 2 bits00: Serving BS release01: HO cancel10: HO reject11: reserved Target_BS_ID48 bitsApplicable only whenHO_IND-type is set to00. HMAC Tuple21 bytesSee 11.4.11}
As illustrated in Table 10, the MOB_HO_IND message includes a plurality of IEs, i.e., a Management Message Type indicating a type of a transmission message, HO_IND_type indicating whether the MSS 200 has determined, canceled or rejected handover to the selected final target BS, ID of the selected final target BS when the MSS 200 determines the handover, and HMAC Tuple used for authentication of the MOB_HO_IND message. The MSS 200 transmits a MOB_HO_RSP message with HO_IND_type=00 when it has determined to perform handover to the final target BS, transmits a MOB_HO_RSP message with HO_IND_type=01 when it has determined to cancel the handover to the final target BS, and transmits a MOB_HO_RSP message with HO_IND_type=10 when it has determined to reject the handover to the final target BS.
Upon receiving the MOB_HO_IND message with HO_IND_type=10, the serving BS 210 updates the candidate target BS list and retransmits a MOB_BSHO_RSP message with the candidate target BS list to the MSS 200.
Upon receiving the MOB_HO_IND message with HO_IND_type=00, the serving BS 210 recognizes that the MSS 200 will perform handover to the target BS included in the MOB_HO_IND message, i.e., the second target BS 230, and releases a connection currently set up to the MSS 200 or retains the connection set up to the MSS 200 for a predetermined time until it receives a report indicating completion of the handover procedure from the target BS finally selected by the MSS 200, i.e., the second target BS 230 in Step 239.
After transmitting the MOB_HO_IND message to the serving BS 210, the MSS 200 performs the remaining handover operation with the second target BS 230.
FIG. 3 is a signaling diagram illustrating a handover process initiated by a BS in a conventional IEEE 802.16e communication system. However, before a description of FIG. 3 is given, it should be noted that the handover initiated by a BS occurs when the BS requires load sharing for dispersing its own load to neighbor BSs due to its excessive load, or when it is necessary to cope with a variation in an uplink state of an MSS.
Referring to FIG. 3, a serving BS 310 transmits a MOB_NBR_ADV message to an MSS 300 in Step 311. The MSS 300 can acquire information on neighbor BSs by receiving the MOB_NBR_ADV message.
In Step 313, if the serving BS 310 detects a handover requirement for the MSS 300 that it is current managing, the serving BS 310 transmits HO_PRE_NOTIFICATION messages to neighbor BSs in Step 315 and 317. Herein, the HO_PRE_NOTIFICATION message includes information on a bandwidth and service level that should be supported by a target BS, which will become a new serving BS of the MSS 300. It will be assumed in FIG. 3 that the neighbor BSs of the serving BS 310 include two BSs of a first target BS 320 and a second target BS 330.
Upon receiving the HO_PRE_NOTIFICATION messages, the first target BS 320 and the second target BS 330 transmit HO_PRE_NOTIFICATION_RESPONSE messages to the serving BS 310 in response to the HO_PRE_NOTIFICATION messages, respectively, in Steps 319 and 321. The HO_PRE_NOTIFICATION_RESPONSE message includes ACK/NACK indicating if the target BSs can perform handover requested by the serving BS 310, and information on a bandwidth and service level supportable to the MSS 300, as described with reference to Table 7.
Upon receiving the HO_PRE_NOTIFICATION_RESPONSE messages from the first target BS 320 and the second target BS 330, the serving BS 310 selects target BSs that can support the bandwidth and service level requested by the MSS 300. For example, if it is assumed that a service level supportable by the first target BS 320 is lower than the service level requested by the MSS 300 and a service level supportable by the second target BS 330 is equal to the service level requested by the MSS 300, the serving BS 310 selects the second target BS 330 as a target BS to which the MSS 300 can be handed over.
After selecting the second target BS 330 as a candidate target BS, the serving BS 310 transmits a Mobile BS Handover Request (MOB_BSHO_REQ) message including the updated candidate target BS list to the MSS 300 in Step 323. Herein, the candidate target BS list can include a plurality of target BSs. A format of the MOB_BSHO_REQ message is illustrated in Table 11.
TABLE 11SyntaxSizeNotesMOB_BHSO_REQ_Message_Format( ) { Management Message Type = 51 8bits For (j=0; j<N_Recommended; j++) {N_Recommendedcan be derivedfrom the knownlength of themessage  Neighbor BS-ID48bits  Service level prediction 8bits }}
As illustrated in Table 11, the MOB_BSHO_REQ message includes a plurality of IEs, i.e., Management Message Type indicating a type of a transmission message and information on the target BSs selected by the serving BS 310.
In Table 11, N_Recommended indicates the number of neighbor BSs selected as candidate target BSs by the serving BS 310, and the MOB_BSHO_REQ message includes IDs for the neighbor BSs indicated by the N_Recommended, and information on a bandwidth and service level supportable to the MSS 300 by the neighbor BSs.
Upon receiving the MOB_BSHO_REQ message, the MSS 300 recognizes that handover has been requested by the serving BS 310, and selects a final target BS to which it will perform handover, based on the N_Recommended information included in the MOB_BSHO_REQ message. Before selecting the final target BS, if the MSS 300 desires to scan CINRs of the pilot signals transmitted from the serving BS 310 and the neighbor BSs, the MSS 300 transmits a MOB_SCN_REQ message to the serving BS 310 in Step 325. Because a time at which the MSS 300 makes a scan request is not directly related to a CINR scanning operation for the pilot signals, a detailed description thereof will not be given herein.
Upon receiving the MOB_SCN_REQ message, the serving BS 310 transmits a MOB_SCN_RSP message including scanning information based on which the MSS 300 will perform scanning, to the MSS 300 in Step 327.
Upon receiving the MOB_SCN_RSP message including the scanning information, the MSS 300 performs CINR scanning on the pilot signals received from neighbor BSs acquired through reception of the MOB_NBR_ADV message, candidate target BSs acquired through reception of the MOB_BSHO_REQ message, and the serving BS 310, according to parameters, i.e., Scan Duration, included in the MOB_SCN_RSP message in Step 329.
After selecting its final candidate target BS, the MSS 300 transmits a Mobile MSS Handover Response (MOB_MSSHO_RSP) to the serving BS 310 in response to the MOB_BSHO_REQ message in Step 331. A format of the MOB_MSSHO_RSP message is illustrated in Table 12.
TABLE 12SyntaxSizeNotesMOB_MSSHO_RSP_Message_Format( ){ Management Message Type = 54 8bits Estimated HO time 8bits For (j=0; j<N_Recommended; j++) {N_Recommendedcan be derivedfrom the knownlength of themessage  Neighbor BS-ID48bits  BS S/(N+1) 8bits }}
As illustrated in Table 12, the MOB_MSSHO_RSP includes a plurality of IEs, i.e., Management Message Type indicating a type of a transmission message, an estimated time at which the handover procedure will start, and information on the target BSs selected by the MSS 310.
In Table 12, N_Recommended indicates the number of neighbor BSs selected as candidate target BSs by the MSS 300, and the MOB_MSSHO_RSP message includes IDs for the neighbor BSs indicated by the N_Recommended, and information on a service level supportable to the MSS 300 by the neighbor BSs.
The serving BS 310 transmits a HO_CONFIRM message to the neighbor BS selected as the final target BS by the MSS 300 in response to the HO_PRE_NOTIFICATION_RESPONSE message in Step 333. After selecting the final target BS, the MSS 330 transmits a MOB_HO_IND message with HO_IND_type=00 to the serving BS 310 in Step 335.
Upon receiving the MOB_HO_IND message with HO_IND_type=00, the serving BS 310 re-recognizes that the MSS 300 will perform handover to the final target BS included in the MOB_HO_IND message, and then releases a connection currently set up to the MSS 300 or retains the connection set up to the MSS 300 for a predetermined time until it receives a report indicating completion of the handover procedure from the finally selected target BS, i.e., the second target BS 330 in Step 337.
After transmitting the MOB_HO_IND message to the serving BS 310, the MSS 300 performs the remaining handover operation with the second target BS 330.
FIG. 4 is a signaling diagram illustrating a network re-entry process upon handover of an MSS in a conventional IEEE 802.16e communication system. Referring to FIG. 4, as an MSS 400 changes its connection to a final target BS 450, the MSS 400 acquires downlink synchronization with the final target BS 450 and then receives a downlink_MAP (DL_MAP) message from the final target BS 450 in Step 411. Herein, the DL_MAP message includes parameters related to a downlink of the final target BS 450.
Further, the MSS 400 receives an uplink_MAP (UL_MAP) message from the final target BS 450 in Step 413. The UL_MAP message includes parameters related to an uplink of the final target BS 450, and includes a Fast UL Ranging IE allocated to support fast UL ranging of the MSS 400 whose handover is being performed by the final target BS 450. The final target BS 450 allocates the Fast UL Ranging IE to the MSS 400 to minimize a possible delay caused by handover. Therefore, the MSS 400 can perform initial ranging with the final target BS 450 on a contention-free basis according to the Fast UL Ranging IE. A format of the Fast UL Ranging IE included in the UL_MAP message is illustrated in Table 13.
TABLE 13SyntaxSizeNotesFast_UL_range IE { MAC address48 bitsMSS MAC address as providedon the RNG_REQ message oninitial system entry UIUC 4 bitsUIUC ≠ 15. A four-bit codeused to define the type of uplinkaccess and the burst typeassociated with that access. OFDM Symbol offset10 bitsThe offset of the OFDM symbolin which the burst starts, the offsetvalue is defined in units of OFDMsymbols and is relevant to theAllocation Start Time field givenin the UL-MAP message. Subchannel offset 6 bitsThe lowest index OFDMAsubchannel used for carryingthe burst, starting from subchannel 0. No. OFDM symbols10 bitsThe number of OFDM symbolthat are used to carry the UL Burst No. Subchannels 6 bitsThe number of OFDMA subchannelswith subsequent indexes, used tocarry the burst. Reserved 4 bits}
In Table 13, Fast_UL_ranging_IE( ) includes a MAC address of an MSS that will be provided with ranging opportunity, an Uplink Interval Usage Code (UIUC) providing information on a field in which a start offset value for the Fast_UL_ranging—IE( ) is recorded, information on an offset of a contention-free-based ranging opportunity interval allocated to the MSS 400, the number of symbols, and the number of subchannels. A MAC address of the MSS 400 has already been reported to the final target BS 450 through messages exchanged between a serving BS and a target BS in a backbone network in the handover process described with reference to FIGS. 2 and 3, like the HO_PRE_NOTIFICATION/HO_PRE_NOTIFICATION_RESPONSE/HO_CON FIRM messages.
Upon receiving the UL_MAP message, the MSS 400 transmits a Ranging Request (RNG_REQ) message to the final target BS 450 according to the Fast UL Ranging IE in Step 415. Upon receiving the RNG_REQ message, the final target BS 450 transmits a Ranging Response (RNG_RSP) message including information for correcting frequency, time and transmission power for the ranging, to the MSS 400 in Step 417.
After completing the initial ranging, the MSS 400 and the final target BS 450 perform a re-authorization operation on the MSS 400 (MSS RE-AUTHORIZATION) in Step 419. In the process of the re-authorization operation, if there is no change in security context exchanged between an old (or former) serving BS of the MSS 400 and the final target BS 450, the final target BS 450 uses the security context intact. A format of an MSS Information Response (MSS_INFO_RSP) message, which is a backbone network message for providing security context information of the MSS 400, is illustrated in Table 14.
TABLE 14FieldsSizeNotesGlobal Header152-bitFor (j=0; j<Num Records; j++) { MSS unique identifier 48-bit48-bit uniqueidentifier used byMSS (as providedby the MSS or bythe I-am-host-ofmessage) N_NSIENumber of NetworkService InformationElements For (k=0; k<N_NSIE; k++) {  Field Size 16-bitSize of TLVencoded informationfield below  TLV encoded informationVariableTLV informationas allowed on aDSA-REQ MACmessage } N_SAIENumber of SecurityAssociatedInformationElements For (k=0; k<N_SAIE; k++) {  Field Size 16-bitSize of TLVencodedinformationfield below  TLV encoded informationVariableTLV informationas allowed aPKM-xxx MACmessage } N_MSS_CAPNumber of MSSCapabilities For (k=0; k<N_MSS_CAP; k++) {  Field Size 16-bitSize of TLVencodedinformationfield below  TLV encoded informationVariableTLV informationas allowed ona SBC-REQMAC message } TLV encoded informationVariableTLV information asallowed on aSBC-REQ MACmessage}Security fieldTBDA means toauthenticate thismessageCRC field 32-bitIEEE CRC-32
In Table 14, the MSS_INFO_RSP message includes ID information of an MSS registered in a serving BS, security context information such as Security Association Information for each MSS, network service information for each MSS, and capability information of each MSS.
When the re-authentication operation for the final target BS 450 and the MSS 400 is completed, the MSS 400 transmits a Registration Request (REG_REQ) message to the final target BS 450 in Step 421. The REG_REQ message includes registration information of the MSS 400. The final target BS 450 transmits a Registration Response (REG_RSP) message to the MSS in response to the REG_REQ message in Step 423. Herein, the final target BS 450 can recognize the MSS 400 as an MSS that has been handed over thereto, by detecting registration information of the MSS 400 included in the REG_REQ message received from the MSS 400.
Accordingly, the final target BS 450 maps connection information in the old serving BS of the MSS 400 to connection information in the final target BS 450, and transmits to the MSS 400 the REG_RSP message including TLV values based on which a service flow that can be actually provided in the final target BS can be reset. A format of the TLV including mapping information for connection setup in the serving BS and the final target BS 450 is illustrated in Table 15.
TABLE 15TypeLengthName(1 byte)(1 byte)Value (Variable-length)New_CID2.12New CID after handoverto new BSOld_CID2.22Old CID before handoverfrom old BSConnection Info2.3VariableIf any of the service flowparameters change, thenthose service flow parametersand CS parameter encodingTLVs that have changed will beadded. Connection_Infois a compound TLV value thatencapsulates the Service FlowParameters and the CSParameter that have changedfor the service. All the rules andsettings that apply to theparameters when used in theDSC-RSP message apply to thecontents encapsulated in thisTLV.
In Table 15, the TLV included in the REG_RSP message provides CID information used in the old serving BS before handover of the MSS 400, and CID information to be used in the final target BS 450 after handover of the MSS 400. In addition, when the final target BS 450 provides a service that is different from the service flow provided by the old serving BS before a handover, the TLV includes information on the changed service parameters.
After completing the network re-entry procedure with the final target BS 450, the MSS 400 performs a normal communication service through the final target BS 450 in Step 425.
As described above, in the IEEE 802.16e communication system, when a CINR of a pilot signal transmitted by a serving BS decreases such that an MSS cannot maintain communication with the current serving BS, the MSS is handed over to a neighbor BS different from the serving BS, i.e., a final target BS, according to a request of the MSS or a request of the serving BS. However, in the IEEE 802.16e communication system, when the MSS cannot perform a communication service through the final target BS due to a decrease in CINR of the pilot signal transmitted by the final target BS in a process of performing a network re-entry operation with the final target BS, the MSS may change its connection back to the serving BS.
However, after the MSS changes its connection to the serving BS due to the foregoing pingpong effect in a process of performing a handover operation with the final target BS, the MSS should perform an initial connection setup procedure with the serving BS, i.e., perform a network re-entry operation, in order to resume the communication service through the serving BS. Therefore, when the pingpong effect frequently happens while the MSS is performing handover, the MSS frequently performs the network re-entry operation, increasing service delay. The frequent implementation of the network re-entry operation also increases a signaling load, causing a reduction in the entire system performance.